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Abstract 

Historically,  the  DoD  Architecture  Framework  has  been  used  for  designing  new  systems. 
Recently  though,  architectural  work  that  was  developed  for  Fleet  Battle  Experiment  India 
(FBE  I)  was  used  to  define  the  framework  for  the  Mission  Capability  Package  (MCP)  for 
Naval  Time  Critical  Targeting  (TCT).  The  architecture  products  were  used  to  describe, 
assess  and  choose  investment  strategies  leading  to  a  more  capable  and  efficient 
integration  of  systems  that  would  produce  the  desired  mission  capability.  The  resulting 
analysis  provided  insights  for  improving  the  networking  of  sensors  C2  and  weapons 
systems.  Additionally,  the  architecture  methods  also  provided  insights  on  particular  areas 
of  the  architecture  where  there  might  be  system  duplications  and  gaps  in  executing  the 
activities  required  by  the  operators. 

This  paper  summarizes  an  architectural  methodology  that  can  be  used  to  enable  a 
capabilities  based  approach  to  the  planning  and  acquisition  of  DOD  families  of  systems 
(FoS)  that  must  interoperate  with  each  other  in  the  conduct  of  military  operations.  While 
individual  systems  within  the  FoS  can  have  substantial  mission  capabilities,  it  is  the 
collective  capability  of  the  FoS  operating  synergistically  that  is  the  objective  of  the  FoS 
systems  engineering  process.  This  requires  that  mission  capabilities  are  traceable  to 
systems  interoperability  in  order  for  designers  and  planners  to  choose  the  correct  FoS. 
Systems  that  operate  synergistically  to  achieve  (collective)  mission  capabilities  must  be 
aligned  in  program  planning,  acquisition,  certification,  and  deployment.  This  paper 
focuses  on  FoS  systems  engineering  aspects  of  planning  and  acquisition  and  shows  how 
the  architectural  products  developed  for  experimentation  were  used  in  both  FBE  I  and  the 
Naval  TCT  MCP. 
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Introduction 

Over  the  past  year  the  Assistant  Secretary  of  the  Navy  for  Research,  Development  and 
Acquisition  Chief  Engineer  of  the  Navy  (ASN  (RDA)  CHENG)  under  the  direction  of 
RADM  Mathis  conducted  a  rigorous  analysis  of  Time  Critical  Targeting  (TCT)  using 
architectural  methods.  Dr.  Dickerson,  the  Director  of  Architectures  for  the  ASN  (RDA) 
CHENG  and  CAPT  (USN  Ret)  Soules,  Principal  from  Booz  Allen  and  Hamilton,  led  a 
government  and  contractor  team  that  used  the  Naval  Warfare  Development  Center 
(NWDC)  Fleet  Battle  Experiment  India  (FBE  I)  to  assess  new  architectural  methods  for 
analysis.  This  effort  evaluated  the  TCT  portion  of  the  FBE  I  experiment  which  focussed 
on  how  C2  Doctrine  changes  combined  with  new  networks  could  possibly  lead  to  an 
implementation  of  Network  Centric  Warfare.  The  architecture  products  used  were  in 
compliance  with  the  DOD  Architecture  Framework  Document  2.0  but  were  used  in  a 
unique  fashion  to  attempt  to  assess  the  TCT  architecture  to  assist  in  making  acquisition 
decisions  for  the  Naval  POM  04  TCT  Mission  Capability  Package  (MCP). 

CNO  N70  and  ASN  (RDA)  CHENG  have  used  these  architecture  products  in  conjunction 
with  other  engineering  and  programmatic  products  to  support  the  development  of  the 
Naval  TCT  Mission  Capability  Package  (MCP).  CNO  N70  is  responsible  for  the 
development  and  integration  of  the  Mission  Capability  Packages.  ASN  (RDA)  CHENG  is 
the  senior  Naval  technical  authority  for  the  overall  architecture,  integration,  and 
interoperability  of  Combat,  Weapons,  and  Command,  Control,  Communications, 
Computer  and  Intelligence  (C4I)  Systems. 

An  Architectural  Methodology 

Because  collective  mission  capabilities  derive  from  the  inter-relations  and  dependencies 
between  the  systems,  the  complexity  of  the  description  of  the  FoS  increases  rapidly  as  we 
proceed  from  high  level  concepts  to  their  instantiation  by  physical  systems.  The 
architectural  methodology  is  part  of  a  systems  engineering  discipline  that  documents 

“the  structure  of  components,  their  relationships,  and  ‘the  principles  and  guidelines 
governing  their  design  and  evolution  over  time”.1 

The  architecture  is  the  first  level  of  design  that  can  be  reasoned  about.  It  provides  the 
framework  for  engineering  development  as  well  as  for  the  operational  uses  of  the  FoS.  It 
also  provides  the  basis  for  the  transformation  of  FoS  planning  and  acquisition  into  a 
capabilities  based  strategy. 

The  Framework  Architecture  products  can  be  organized  into  five  groups,  or  use  cases  for 
the  products  that  support  FoS  systems  engineering  and  acquisition: 

■  Operational  Concept 

■  System  Functional  Mapping 

■  System  Interface  Mapping 


1 IEE  Standard  610.12  as  adapted  by  the  DOD  Architecture  Framework  2.0 
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■  Architecture  Performance  and  Behavior 

■  Acquisition  Strategy 

In  figure  1,  these  groups  are  generally  ordered  (top  to  bottom)  by  the  level  of  complexity 
anticipated  for  their  use.  How  architectures  provide  the  framework  for  FoS  systems 
engineering  and  acquisition  is  the  subject  of  the  remainder  of  this  section. 

The  first  four  of  the  five  groups  of  products  can  be  generally  associated  with  the  four 
steps  of  classical  systems  engineering: 

■  Requirements  Analysis 

■  Functional  Analysis 

■  Synthesis 

■  Design  Verification 

While  FoS  systems  engineering  must  follow  the  principles  of  classical  systems 
engineering,  the  complexity  of  the  FoS  and  the  preponderance  of  legacy  systems  in  the 
FoS  will  limit  in  practice  the  system  engineer’s  ability  to  apply  these  principles. 
Requirements  analysis  and  the  functional  design  of  the  FoS  to  achieve  specific 
capabilities  can  be  a  manageable  task.  These  become  stable  views  of  the  FoS  that  are 
much  simpler  to  understand  than  the  underlying  and  constantly  changing  physical 
architecture.  Synthesis  then  becomes  a  mapping  of  the  legacy  systems  in  the  FoS  into  the 
functional  view  of  the  architecture  and  a  determination  of  how  to  use  the  remaining  trade 
space  for  new  systems  and  system  improvements.  Design  verification  for  the  FoS  is 
reduced  in  complexity  by  focusing  on  threads  of  systems  that  provide  the  supporting 
functionality  for  specific  mission  capabilities. 

Operational  Concept 

The  operational  concept  should  be  a  high  level  abstraction  of  the  problem  to  be  solved 
and  the  proposed  approach  to  solve  the  problem.  It  can  also  include  boundary  conditions 
and  invariants  (i.e.,  things  not  in  the  trade  space  of  the  solution).  Three  Architecture 
Framework  products  can  be  used  to  support  description  of  the  operational  concept: 

■  OV-1:  High  Level  Operational  Concept  Graphic 

■  OV-5:  Activity  Model 

■  OV-4:  Command  Relationships  Chart 

These  products  lay  the  foundation  for  systems  development  and  facilitate  communication 
by  providing  context,  orientation,  and  focus.  They  also  serve  as  the  entry  point  for 
requirements  flow  down  into  the  architecture. 

OV-1  (High  Level  Operational  Concept  Graphic)  This  view  should 
provide  a  high  level  description  of  what  the  military  force  is  and  its  intended  effects  on 
the  defined  threat.  It  should  also  establish  the  boundaries  of  the  battlespace  and  the  uses 
of  the  military  force  to  achieve  effects.  For  the  purpose  of  this  initial  work,  we  defined  a 
mission  capability  as  the  possession  of  the  means  to  use  military  force  to  achieve  an 
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intended  effect  within  the  battlespace.  It  is  also  reasonable  to  use  the  OV-1  to  describe 
an  evolution  of  capability  increments  that  lead  to  full  capability.  Uses  of  the  OV-1  for 
systems  engineering  must  also  be  tied  to  a  Design  Reference  Mission  (DRM), 
Operational  Situations  (OpSits)  and  Tactics,  Techniques  and  Procedures  (TTP).  These 
are  indicated  as  faded  boxes  in  figure  1 . 


Using  Architectures  in  Systems 
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System  Functional  Mapping 


Capabilities  Evolution  Description 
High-level  Operational  Concept  Graphic 
Operational  Node  Connectivity  Description 
Operational  Information  Exchange  Matrix 
Command  Relationships  Chart 
Activity  Model 

Operational  Event/Trace  Description 
System  Interface  Description 
Systems  Communication  Description 
Systems  Matrix 

System  Functionality  Description 
Operational  Activity  to  System  Function 
Traceability  Matrix 

System  Information  Exchange  Matrix 
System  Performance  Parameters  Matrix 
System  Evolution  Description 
System  Technology  Forecast 
System  Activity  Sequence  &  Timing 
Technical  Architecture  Profile 
Standards  Technology  Forecast 


DRM:  Design  Reference  Mission 
OpSit:  Operational  Situation 
TTP:  Tactics,  Techniques,  Procedures 


Note:  There  are  dependencies  between  the  Architecture 
products  that  are  not  shown  in  the  System 
Engineering  flow.  Many  of  the  products  are 
developed  concurrently. 


Architectures  Provide  the  Framework  for 
FoS/SoS  Systems  Engineering  &  Acquisition 


3rd  Order  Analysis: 
Dynamic  Interoperability 


Using  Architectures  in  FoS/SoS  Systems  Engineering  and  Acquisition 

Figure  1 


OV-5  (Activity  Model)  This  view  should  provide  the  first  descriptions  of 
how  the  military  force  will  achieve  its  intended  effects.  Each  use  of  military  force  (from 
the  OV-1)  must  be  enabled  by  one  or  more  operational  activities.  These  activities,  along 
with  the  input  or  output  of  data  and  services  between  them,  form  the  activity  model  (e.g., 
an  IDEF-0).  However,  no  order  of  execution  or  timing  relations  need  be  established  at 
this  point.  A  paradigm  of  five  high  level  activities  can  be  used  to  organize  most 
operational  activities:  monitor,  assess,  plan,  execute,  sustain.  The  execution  activity  can 
take  on  different  meanings.  In  combat  systems  it  can  mean  either  combat  direction  (e.g., 
C2)  or  engagement  (e.g.,  weapons  delivery). 

OV-4  (Command  Relationships  Chart)  This  view  documents  the  control 
relations  over  the  operational  activities,  establishing  by  what  authority  or  mechanisms 
activities  are  directed  to  execute  or  remain  idle.  It  is  the  basis  for  C2  relations  in  the 
architecture. 
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System  Functional  Mapping 

Due  to  the  complexity  of  the  FoSs  of  interest,  simply  bookkeeping  the  data  describing  the 
systems,  their  relationships,  and  evolution  is  an  overwhelming  task.  The  functional  view 
of  the  solution  provides  a  stable  model  which  is  easier  to  manage  and  against  which  the 
FOS  can  be  mapped.  Three  Architecture  Framework  products  support  the  system 
functional  mapping: 


■  SV-4:  System  Functionality  Description 

■  SV-5:  Operational  Activity  to  System  Function  Traceability  Matrix 

■  SV-3:  Systems  Matrix 


Together,  these  products  provide  the  linkage  and  traceability  of  capabilities  and 
requirements  flowdown  between  the  operational  and  the  physical  views.  The  functional 
view  is  also  the  first  level  of  the  architecture  that  is  appropriate  for  systems  assessments. 
The  products  provide  the  basis  to  answer  the  question:  Does  the  FoS  system  architecture 
provide  the  functionality  to  support  the  desired  mission  capabilities? 


Assessments  using  this  functional  group  of  products  provide  the  basis  for  a  first  order 
analysis  of  combinations  of  systems  proposed  to  comprise  the  FoS.  In  the  systems 
engineering  process,  our  attention  will  be  on  an  FoS  that  is  intended  to  solve  the 
problems  laid  out  in  the  OV-1.  For  example:  an  analysis  of  gaps  and  duplications  reduce 
the  size  of  the  system  trade  space.  The  result  of  the  first  order  architecture  analysis  is  the 
starting  point  for  systems  engineering  analysis. 

SV-4  (System  Functionality  Description.  This  Architecture  Framework  product  is 
more  useful  for  FoS  system  engineering  when  it  is  broken  into  three  views  that  would 
revise  the  Framework: 


SV-4a:  List  of  Systems  Functions 
SV-4b:  System  Functional  View  (SFV) 

SV-4c:  Logical  Interface  View  (LIV) 

The  SV-4a  is  the  list  of  system  functions  that  will  be  used  to  enable  or  execute  the 
operational  activities. 

SV-5  (Operational  Activity  to  System  Function  Traceability  Matrix)  This  is  a 
matrix  that  summarizes  which  individual  system  functions  are  used  to  enable  or  execute 
which  individual  operational  activities.  Each  cell  in  the  matrix  points  to  a  use  case  of  the 
system  functions.  Using  the  system  functions,  the  SV-5  provides  the  traceability  of 
operational  capabilities  into  the  FoS. 

SV-4b  (System  Functional  View)  The  SFV  is  derived  from  the  OV-5  using  the 
SV-5.  It  is  the  functional  analog  of  the  activities  model  and  shows  the  relationships  and 
dependencies  amongst  the  system  functions. 
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SV-4c  (Logical  Interface  View)  The  LIV  uses  the  OV-5  input/output  relations  to 
build  the  logical  interfaces  between  the  related  functions  in  the  SFV.  This  view  can  be 
represented  as  an  overlay  to  the  SFY  or  as  a  hyperlinked  drill  down  on  the  connections 
between  the  functions. 

SV-3  (Systems  Matrix)  This  Architecture  Framework  product  is  more  useful  for 
FoS  systems  engineering  when  it  is  broken  into  three  views  that  would  revise  the 
Framework: 


SV-3a:  Systems  to  Functions  Matrix 

SV-3b:  Operational  Activity  to  System  Traceability  Matrix 

SV-3c:  Systems  Matrix 

The  SV-3a  is  a  matrix  that  summarizes  which  individual  physical  systems  are  used  to 
enable  which  individual  system  functions.  Each  cell  of  the  matrix  points  to  a  functional 
use  case  of  the  physical  systems.  Using  the  systems  functions  and  the  SV-5,  the  SV-3a 
provides  the  direct  traceability  of  operational  capabilities  into  the  physical  systems  of  the 
FoS.  This  results  in  a  matrix,  (the  SV-3b),  that  is  analogous  to  the  SV-5  but  at  the 
physical  level.  Each  cell  of  the  SV-3b  matrix  points  to  an  operational  use  case  of  the 
physical  systems.  The  SV-3c  is  in  the  form  the  Systems2  matrix  of  the  Framework,  but  in 
this  methodology  is  built  using  the  relations  between  system  functions  provided  by  SV- 
4b  (SFV).  The  logical  interfaces  of  the  SV-4c  taken  with  the  SV-3c  can  be  used  to  begin 
building  a  physical  instantiation  of  the  OV-3,  which  is  indicated  in  figure  1  as  a  faded 
box. 

System  Interface  Mapping 

The  system  interface  mapping  builds  all  views  of  the  connectivity  between  the  systems  in 
the  FoS:  operational,  system,  and  technical.  Six  Architecture  Framework  products  can 
be  used  to  support  the  system  interface  mapping: 

■  OV-2:  Operational  Node  Connectivity  Description 

■  SV-1:  System  Interface  Description 

■  TV-1:  Technical  Architecture  Profile 

■  OV-3:  Operational  Information  Exchange  Matrix 

■  SV-2:  Systems  Communication  Description 

■  SV-6:  System  Information  Exchange  Matrix 

From  the  point  of  view  of  systems  engineering  trades,  these  views  provide  the  basis  to 
answer  the  question:  Have  the  appropriate  standards  been  applied  and  the  levels  of 
interoperability  been  properly  aligned  so  that  the  individual  systems  in  the  FoS  can  be 
expected  to  interoperate  with  each  other  successfully  to  enable  the  functionality  sought 
for  the  FoS  ? 
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OV-2  (Operational  Node  Connectivity  Description)  The  operational  nodes  in  this 
view  are  meaningful  groupings  of  the  activities  in  the  OV-5  (Operational  Activity 
Model).  These  nodes  are  associated  with  physical  or  organizational  nodes  in  other  views 
of  the  architecture.  They  can  be  thought  of  as  task-oriented  cells  where  work  is 
accomplished.  Because  the  activities  of  the  OV-5  carry  input  and  output  relations,  the 
nodes  of  the  OV-2  inherit  these  relations,  which  are  usually  referred  to  as  need  lines. 
From  a  systems  engineering  point  of  view,  the  nodes  in  the  OV-2  should  be  created  to 
establish  natural  lines  of  communication  between  physical  locations.  When  the 
architecture  is  physically  instantiated,  communication  occurs  between  operational  nodes, 
vice  between  activities.  However,  need  lines  are  not  the  communications  paths.  (The 
communications  paths  are  described  in  the  SV-2). 

SV-1  (System  Interface  Description)  This  view  links  the  operational  and  system 
views  of  the  architecture.  The  SV-3b  (Operational  Activity  to  System  Traceability 
Matrix)  provides  the  linkage.  At  the  highest  level,  the  SV-1  organizes  the  systems  along 
the  paradigm  of  monitor,  assess,  plan,  execute,  sustain  (possibly  with  the  C2  aspect  of 
execution,  i.e.  combat  direction,  being  separated  from  the  engagement  aspect  of 
execution,  e.g.  weapons  delivery).  This  representation  relates  to  the  OV-1  and  is  useful 
for  high  level  planning.  At  the  systems  engineering  level,  the  SV-1  is  a  mapping  of 
systems  to  the  OV-2  using  the  SV-3b.  The  associated  operational  and  system  need  lines 
are  in  concordance  because  of  their  common  derivation  through  the  SV-5. 

TV-1  (Technical  Architecture  Profile)  The  Architecture  Framework  represents 
the  technical  component  of  the  architecture  as  the  set  of  rules  that  govern  system 
implementation  and  operation.  In  this  sense,  the  TV-1  should  go  beyond  interface 
standards  and  protocols.  In  practice,  the  TV-1  is  frequently  seen  as  only  the  list  of 
standards  and  protocols  associated  with  the  transport  layer  of  interfacing  and 
communications  between  systems.  However,  in  the  Framework  2.0  the  notional  example 
of  the  TV-1  addresses  service  areas,  services,  and  standards  that  go  beyond  interfaces. 
Therefore,  it  may  be  appropriate  to  decompose  the  TV-1  into  interface  standards  that 
align  to  an  overarching  accepted  standard  like  OSI  and  into  other  standards  related  to 
services  and  physical  systems. 

OV-3  (Operational  Information  Exchange  Matrix)  This  Architecture  Framework 
product  can  be  adapted  to  our  FoS  system  engineering  process  by  deriving  it  from  the 
operational  and  system  architecture  products  already  developed.  The  Architecture 
Framework  defines  the  Information  Exchange  Requirements  (IERs)  of  the  OV-3  view  as 
the  relationship  across  the  three  basic  entities  of  the  operational  view  of  the  architecture 
(activities,  operational  nodes,  and  information  flow)  as  a  focus  on  the  specific  aspects  of 
information  flow,  namely  who  exchanges  what  information  with  whom,  why  the 
information  is  necessary,  and  in  what  manner.  The  OV-3  was  intended  to  emphasize  the 
logical  and  operational  characteristics  of  the  information.  However,  the  fundamental 
operational  information  exchanges  are  really  identified  at  the  activity  level  in  the  OV-5 
via  the  input  and  output  relations.  With  our  adaptation  of  the  OV-2  as  meaningful 
groupings  of  activities  (cells  where  work  is  done)  to  establish  communication  need  lines, 
the  OV-2  becomes  the  more  natural  starting  point  for  building  the  OV-3.  If  the  non- 
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physical  standards  and  protocols  from  the  TV-1  are  applied  to  these  need  lines,  then  a 
systematic  and  well  organized  operational  view  of  information  exchange  is  accomplished 
and  a  foundation  for  the  System  Information  Exchange  Matrix  is  established. 

SV-2  (Systems  Communication  Description)  This  view  represents  the  specific 
communications  systems  pathways  or  networks  and  the  details  of  their  configurations 
through  which  the  physical  nodes  and  systems  interface.  This  product  focuses  on  the 
physical  aspect  of  the  information  need  lines  represented  in  the  OV-2  (Operational  Node 
Connectivity  Description).  It  describes  all  pertinent  communications  aspects  of  the  FoS, 
showing  the  details  of  need  lines  between  the  systems  identified  by  the  SV-1  (System 
Interface  Description). 

SV-6  (System  Information  Exchange  Matrix)  This  Architecture  Framework 
product  is  made  more  useful  for  FoS  system  engineering  by  expanding  it  into  a  broader 
view  that  would  revise  the  Framework.  This  expanded  SV-6  would  retain  the  attributes 
of  the  existing  Framework  product,  which  is  defined  as  the  information  exchanges  within 
a  node,  and  from  those  systems  to  systems  at  other  nodes.  It  is  easily  derived  from  the 
OV-3,  TV-1,  SV-3b  and  the  SV-3c.  This  makes  the  SV-6  the  system  analog  to  the  OV-3. 
The  stronger  SV-6  product  can  be  derived  because  the  matrices  of  the  preceding 
architecture  products  can  be  used  to  create  end-to-end  views  of  system  information  and 
service  exchanges.  Each  communication  and  service  between  two  systems  can  trace  the 
capabilities,  activities,  functionality,  logical  and  technical  interfaces  of  the  architecture. 

Architecture  Performance  and  Behavior 

The  system  functional  mapping  and  the  system  interface  mapping  provide  key  insights 
into  the  functionality  and  connectivity  of  the  architecture  with  traceability  to  operational 
capability.  As  such,  these  uses  of  Framework  Architecture  products  provide  an  early 
validation  of  the  architecture  and  serve  to  answer  the  question:  What  can  the  architecture 
enable  the  FoS  to  actually  do?  However,  the  architecture  is  not  (abstractly)  validated 
until  it  can  be  executed  as  a  flow  of  events,  which  is  accomplished  through  the  products 
of  performance  and  behavior.  The  group  of  architecture  products  proposed  for  the  use 
case  of  performance  and  behavior  can  serve  to  answer  the  questions:  how  well  does  the 
architecture  perform  (to  deliver  mission  capabilities )  and  does  it  behave  in  ways 
acceptable  to  the  users?  Three  Architecture  Framework  products  support  this  use  case 
and  one  new  product  must  be  added: 

■  OV-6c:  Operational  Event/Trace  Description 

■  SV-10:  System  Activity  Sequence  &  Timing  Description 

■  SV-7:  System  Performance  Parameters  Matrix 

■  Executable  Model  (new  product) 

These  products  are  necessary  to  support  system  selection  decisions,  which  reside  in  the 
domain  of  FoS  systems  engineering  trade  studies  (i.e.,  performance  and  capabilities  vs. 
cost  and  risk).  However,  these  products  are  the  most  labor  intensive  of  the  five  groups 
(use  cases)  to  generate. 
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0V-6c  (Operational  Event/Trace  Description)  This  view,  which  is  sometimes 
called  a  sequence  diagram,  is  the  most  basic  product  which  addresses  the  executability 
(or  dynamic  validity)  of  the  operational  view  of  the  architecture.  It  enables  the 
traceability  of  actions  in  a  scenario  or  critical  sequence  of  events.  The  OV-6c  organizes 
the  OV-5  activities  around  the  OV-2,  using  the  OV-4  for  control  (or  triggering)  of 
architecture  responses  to  scenario  events.  It  introduces  timing  and  sequencing  into  the 
activity  model  (OV-5).  Insights  into  dynamic  validity,  throughput,  and  node  loading  are 
gained.  However,  it  does  not  address  architecture  performance.  The  performance  of  the 
architecture  is  determined  by  the  performance  of  the  systems  and  personnel  that  enable  or 
execute  the  operational  activities. 

SV-10  (System  Activity  Sequence  &  Timing  Diagram)  This  view  should  be 
inherited  from  the  OV-6  using  the  mapping  of  the  SV-5  and  other  SV-3,4  products.  The 
Architecture  Framework  calls  out  three  systems  models  that  are  needed  to  accomplish  the 
complete  description: 

■  SV-lOa:  Systems  Rules  Model 

■  SV-lOb:  Systems  State  Transition  Description 

■  SV-lOc:  Systems  Event/Trace  Description 

There  is  another  view  that  has  proven  very  useful  in  architecture  assessments.  This 
proposed  view  would  be  a  fourth  product  that  logically  should  proceed  from  the  three 
standard  SV-10  Framework  Products  and  is  what  is  labeled  an  SV-lOd. 

SV-lOd:  (Systems  to  Operational  Sequence  Mapping)  This  view  is  a  simple 
mapping  of  the  SV-3b  to  the  OV-6c.  The  result  is  an  OV-6c  with  physical  systems 
associated  with  the  activity  flow  of  the  OV-6c.  Military  operators  find  this  very  useful. 
Derivation  of  this  view  through  the  SV-3b  adds  engineering  discipline  to  the  association 
of  physical  systems  and  operational  activities.  Still  though,  architecture  performance  is 
not  observable  until  the  performance  metrics  of  the  individual  systems  are  determined, 
which  is  the  purpose  of  the  SV-7. 

SV-7  (System  Performance  Parameters  Matrix)  This  view  builds  on  the  System 
Element  Interface  Description  (SV-1)  to  depict  the  current  performance  characteristics  of 
each  system,  and  the  expected  or  required  performance  characteristics  at  specified  times 
in  the  future.  The  expected  characteristics  relate  to  the  System  Evolution  Description 
(SV-8),  whereas  the  performance  requirements  for  physical  systems  are  traceable  only 
when  an  allocated  baseline  has  been  established  (i.e.,  functions  and  requirements  have 
been  allocated  to  physical  systems).  Building  the  allocated  baseline  requires  the 
collaboration  of  multiple  stakeholders  and  is  in  the  domain  of  FoS  systems  engineering 
trades  that  occur  during  synthesis. 

Executable  Model  Execution  of  the  architecture  is  required  for  both  validation 
and  analysis.  A  number  of  popular  tools  are  available.  RDA  CHENG  currently  has  been 
using  a  popular  tool  developed  for  structured  analysis.  However,  future  work  will  move 
towards  object  orientation  using  the  Universal  Modeling  Language  (UML).  This  will 


10 


allow  for  better  re-use  of  the  architecture  products  and  provide  better  control  of  attributes 
through  the  inheritance  properties  of  UML.  The  organization,  description,  and  uses  of 
the  Architecture  Framework  products  in  this  paper  have  been  written  with  extensibility  to 
UML  in  mind,  while  preserving  the  structured  analysis  attributes  of  classical  systems 
engineering. 

Acquisition  Strategy 

A  capabilities  based  acquisition  strategy  aligns  the  evolution  of  systems,  technologies, 
and  standards  into  an  acquisition  strategy  to  support  the  evolving  capabilities  needed  for 
the  FoS.  Three  Architecture  Framework  products,  and  a  new  proposed  product,  are 
needed  to  support  the  description  of  the  acquisition  strategy: 

■  SV-9:  System  Technology  Forecast 

■  TV-2:  Standards  Technology  Forecast 

■  SV-8:  System  Evolution  Description 

■  CV-6:  Capability  Evolution  Description 

Together,  these  products  provide  a  description  of  the  evolution  and  acquisition  of  the 
system  improvements  to  the  FoS  that  is  traceable  to  mission  capabilities. 

SV-9  (System  Technology  Forecast)  A  system  Technology  Forecast  is  a  detailed 
description  of  emerging  technologies  and  specific  hardware  and  software  products.  It 
contains  predictions  about  the  availability  of  emerging  capabilities  and  about  industry 
trends  in  specific  timeframes  (e.g.,  6-month,  12-month,  18-month  intervals),  and 
confidence  factors  for  the  predictions.  The  forecast  includes  potential  technology 
impacts  on  current  architectures,  and  thus  influences  the  development  of  transition  and 
objective  architectures.  The  forecast  should  be  tailored  to  focus  on  technology  areas  that 
are  related  to  the  purpose  for  which  a  given  architecture  is  being  build,  and  should 
identify  issues  that  will  affect  the  architecture. 

TV-2  (Standards  Technology  Forecast)  A  Standards  Technology  Forecast  is  a 
detailed  description  of  emerging  technology  standards  relevant  to  the  systems  and 
business  processes  covered  by  the  architecture.  It  contains  predictions  about  the 
availability  of  emerging  standards  and  the  likely  obsolescence  of  existing  standards  in 
specific  timeframes  (e.g.,  6-month,  12-month,  18-month  intervals),  and  confidence 
factors  for  the  predictions.  It  also  contains  matching  predictions  for  market  acceptance  of 
each  standard  and  an  overall  risk  assessment  associated  with  using  the  standard.  The 
forecast  includes  potential  standards  impacts  on  current  architectures,  and  thus  influences 
the  development  of  transition  and  objective  architectures.  The  forecast  should  be  tailored 
to  focus  on  technology  areas  that  are  related  to  the  purpose  for  which  a  given  architecture 
description  is  being  built,  and  should  identify  issues  that  will  affect  the  architecture. 

SV-8  System  Evolution  Description)  The  System  Evolution  Description 
describes  plans  for  “modernizing”  a  system  of  suite  of  systems  over  time.  Such  efforts 
typically  involve  the  characteristics  of  evolution  (spreading  in  scope  while  increasing 
functionality  and  flexibility),  or  migration  (incrementally  creating  a  more  streamlined, 
efficient,  smaller  and  cheaper  suite),  and  will  often  combine  the  two  thrusts.  This 
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product  builds  on  the  previous  diagrams  and  analyses  in  that  information  requirements, 
performance  parameters,  and  technology  forecasts  must  be  accommodated. 

In  FoS  systems  engineering,  the  Systems  Evolution  Description  will  draw  heavily  not 
only  from  the  System  Technology  Forecast  (SV-9)  but  also  from  the  Standards 
Technology  Forecast  (TV-2).  This  is  because  the  FoS  derives  its  capabilities  through  the 
interoperation  of  systems,  not  just  through  the  operation  of  individual  systems.  Thus,  the 
evolution  of  system  connectivity  must  be  given  equal  attention  with  individual  system 
evolution. 

CV-6  (Capability  Evolution  Description)  This  new  view  has  been  proposed  and 
considered  by  various  elements  of  the  DOD.  This  view  would  be  a  high  level  graphic 
for  managers  and  executives  to  use  for  oversight  of  FoS  alignment  during  acquisition. 
Portfolios  of  programs  would  be  bundled  by  the  capability  increments  referred  to  in  the 
Operational  Concept  (OV-1).  Increments  of  capability  introduced  over  time  would  then 
establish  the  evolution  of  the  FoS  in  acquisition.  The  delivery  of  systems  and  the 
associated  integration  and  interoperability  strategy  would  be  aligned  and  displayed  in  the 
CV-6  graphic,  so  that  connectivity,  alignment,  and  traceability  to  capabilities  are  all 
displayed  in  one  graphic. 

Applying  The  Architectural  Methodology 

During  the  course  of  the  past  two  years  the  Director  of  Architectures  for  the  Chief 
Engineer  of  the  Navy  office  conducted  a  pilot  program  in  conjunction  with  the  Naval 
Warfare  Development  Center  to  assist  in  analyzing  a  Fleet  Battle  Experiment.  Using  the 
methodology  described  in  the  previous  pages  the  Director  of  Architectures  documented 
the  design  and  execution  of  the  Time  Critical  Targeting  portion  of  the  experiment  using 
the  views  and  products  discussed  in  the  methodology  in  the  previous  section. 

The  FBE  I  views  were  then  compared  and  integrated  with  other  architecture  products 
derived  from  other  Time  Critical  Targeting  efforts  ongoing  in  the  Navy.  The  results  from 
the  integrated  architectures  were  then  presented  to  OpNav  N70  (Integrated  Warfighter 
Requirements)  for  consideration  in  making  POM  04  acquisition  decisions  in  support  of 
the  Time  Critical  Targeting  Mission  Capability  Package. 
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Using  Architectures  &  Analysis  to 
Influence  POM  Decisions 
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Figure  2 

The  FBE  I  pilot  proved  to  be  successful.  The  products  were  documented  and  stored  in 
the  Joint  Mission  Area  Analysis  Tool  (JMAAT)  that  in  turn  provided  a  standard  and 
disciplined  approach  to  capturing  the  operational,  systems  and  technical  views.  Figure  2 
illustrates  the  first  order  assessments  of  FoS  system  functionality  that  were  used  to  make 
decisions  in  the  POM  04  build.  In  addition  key  integration  solutions  were  identified 
which  influenced  priorities  and  decisions  for  investments  that  could  make  a  difference  in 
mission  capability.  As  a  result  of  the  pilot  the  ASN  RDA  CHENG  was  able  to  begin  to 
institutionalize  the  process  across  the  Navy  to  begin  to  address  other  mission  capability 
packages  and  develop  a  common  language  between  the  organizations  that  support  them. 

The  RDA  CHENG  support  of  the  N70  POM04  build  was  used  in  six  of  the  N70  MCPs  to 
various  levels.  Six  attributes  of  each  MCP  were  identified  to  support  MCP  decisions,  as 
illustrated  in  Figure  3.  Analysis  of  four  of  the  six  attributes  were  supported  by 
architectures  products  as  depicted  in  Figure  3,  including  Functional  Analysis,  OpSit 
Analysis,  Interoperability  Analysis,  and  Future  Vision  Analysis. 
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.  The  architectural  methods  proposed  in  this  paper  are  providing  a  means  for  operators, 
engineers  and  acquisition  specialists  to  implement  mission  capabilities  through  a 
common  language  and  approach.  By  evaluating  system  integration  and  interoperability 
as  well  as  the  impacts  on  doctrine,  training,  maintenance  and  logistics  through  out  the 
concept  development,  engineering  and  acquisition  process,  the  ability  to  acquire  fully 
integrated  mission  capable  Family  of  Systems  can  begin  to  become  a  reality 
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